---
title: SAIF.Application.Claim.Legal architecture
summary: Architectural responsibilities, boundaries, and interaction patterns for the Legal-claim application (AppManager) tier.
status: draft
owner: SAIF Documentation Pipeline
last_reviewed: 2026-08-21
library: SAIF.Application.Claim.Legal
reference_type: embedded
---

# SAIF.Application.Claim.Legal architecture

`SAIF.Application.Claim.Legal` is the Application/orchestration ("AppManager") tier for legal-case (WCB/DCBS appeal) management. It sits directly beneath the `Legal\` web front end and directly above the `SAIF.Business.Claim.Legal` business-object tier, translating UI screen actions into business-object CRUD calls, applying screen-level validation and authorization, and bridging to external systems (Guidewire, Appworx print batch) and application-layer Oracle SQL.

## Responsibilities
- Translate UI screen actions (one `*Manager` class per screen/workflow area — Assignment, Appeal, Board Log, Case Cost, Case Notes, Case Search, Create File, Mail Date, Other Parties, Outcome, Quick Cal, Request, Schedule, Summary, Update Case, and Attorney/Hearing-Location/Person maintenance) into business-object retrieve/save calls.
- Enforce screen-level and claim-level authorization (`SecurityPrincipal.IsAuthorized(<resourceKey>)`, `LegalManagerBase.OnRetrieve()` conflict/exposure gating).
- Manage legal-case context selection and creation (`SetCurrentCase`, `CreateCase`, `OnContextChanged`) and consolidated-case propagation (file location, LCE due date, case status, DEF flag).
- Execute a small set of application-layer (non-`IBusinessCriteria`) Oracle SQL statements and one stored-procedure execute (`pk80001_LEGALNET.insertLetterRequest`) directly from manager classes.
- Cache largely-static code-table lookups (attorney/hearing-location/person/case-status code lists) in `HttpContext.Current.Cache` for 8 hours to reduce Oracle round-trips.
- Integrate with external systems: Appworx batch print submission for letters (Create File, Mail Date, DEF), and Guidewire claim-system REST APIs for matter/activity sync (Assignment, Schedule, Request managers).

## Component boundaries
- **`LegalManagerBase`** (`MustInherit`, inherits `ClaimAppManager` from `SAIF.Application.Claim`) — the shared boundary for every concrete manager: case-context lifecycle, claim-level conflict/exposure authorization, consolidated-case propagation helpers, and the direct stored-procedure call `insertLetterRequest`.
- **22 concrete `*Manager` classes** (e.g., `clsAppealManager`, `clsScheduleManager`, `clsRequestManager`, `clsAttorneyTableManager`) — one per screen/workflow area, each owning its own business-object collaboration, validation, and (in a few cases) external-integration logic.
- **`clsLegalData`** (inherits `clsBusinessBase`† from `SAIF.Framework.Core`) — a lightweight read-only header holder for a legal case, loaded via the `pk80001_legalNet.getHeader` stored procedure; not part of the `*Manager` hierarchy.
- **DTO/request classes** (`GwActivityRequest`, `GwMatterRequest`, `WcdRequest`) — payload shapes for outbound Guidewire API calls; pure data carriers with no behavior of their own.
- **Data-layer boundary:** this library owns no `IBusinessCriteria` implementations (confirmed by DB analysis); all business-object CRUD SQL for legal-case entities lives in the referenced `SAIF.Business.Claim.Legal` library. This library instead authors application-layer SQL directly against manager classes for code-table lookups, one scalar lookup, and one stored-procedure insert — a distinct, narrower data-access boundary than the business tier.
- **Web-tier coupling boundary:** several managers (`clsAppealManager`, `clsAttorneyTableManager`) call `System.Web.HttpContext.Current.Cache`/`HttpRequest` directly for AJAX endpoints and caching, coupling this Application-layer library more tightly to the ASP.NET web tier than a strict layered architecture would prescribe*.

## Interaction model
- **Primary control/data flow:** `Legal.vbproj` (web UI) → a `SAIF.Application.Claim.Legal` manager (`New` → `OnInitialize`/`OnContextChanged` → `OnRetrieve`) → `SAIF.Business.Claim.Legal` business objects (`Get*`/`New*` factory methods, `Save()`) → BOF data portal (`IDataPortalInfo`) → Oracle stored procedures/PL-SQL packages (chiefly `pk80001_LEGALNET`/`pk80001_legalNet`). Write flows funnel through each manager's `OnWrite()` override, with several adding `PreSaveProcessing()`/`PostSaveProcessing()` hooks around the business-object `Save()`.
- **Data-layer interaction (this library's own SQL):** application-layer SQL is authored directly in manager classes, bypassing the business/`IBusinessCriteria` layer. Database DB analysis findings catalog 24 statements (`SQL-001`–`SQL-024`): one stored-procedure execute (`pk80001_LEGALNET.insertLetterRequest`, used for DEF and recon-request letters), one stored-procedure result-set retrieve (`pk80001_legalNet.getHeader`, backing `clsLegalData`), one scalar stored-function call (`pk80001_LEGALNET.get_atty_mngr_email`), one scalar inline `SELECT` against `attorney_profile`, and 20 static/constant code-table lookup `SELECT`s executed via `clsCodeCollection.GetCodeCollection` against tables such as `POLICY`, `DURATION_CODE`, `HEARING_LOCATION_CODE`, `LEGAL_PERSON`/`LEGAL_PERSON_TYPE`, `OTHER_FIRM`, `APPEAL`, `REVIEW_LEVEL_CODE`, and `CASE_STATUS_CODE`. All tables are recorded as unqualified (no explicit schema owner)**. See [Database tables](database-tables.md) and the [SQL catalog](sql/index.md) for the full statement-level detail — not duplicated here.
- **External integration boundary (non-BOF):** `clsAssignmentManager`, `clsScheduleManager`, and `clsRequestManager` call out to Guidewire claim-system REST APIs (`GwMatterApi`, `GWActivityData`, `GWClaimDataApi`) via `SAIF.Web.API.Clients`/`SAIF.Web.API.Core`, and to a `ccclaimdataapi` endpoint configured via `EnvironmentService.GetConfigSetting("cc.ccclaimdataapiurl")`*. These calls are wrapped in try/catch with `Logging.clsLogError.CreateError` on failure — a best-effort, fire-and-forget pattern that does not abort the primary save.
- **Batch print integration:** `clsCreateFileManager` and `clsMailDateManager` submit Appworx batch print jobs (`SAIF.Services.Appworx.clsRequestAppworxJob.SubmitBatchJob`) for letters and cover letters after a letter request is inserted.
- **Inherited framework lifecycle:** every concrete manager, via `LegalManagerBase` → `ClaimAppManager` → `AppManagerBase`, is simultaneously a BOF business object (through the inherited `clsBusinessBase` chain) and an application-process controller with its own parallel `OnInitialize`/`OnRetrieve`/`OnWrite` lifecycle. Per cached Legends CLI RAG findings for `clsBusinessBase` (`SAIF.Framework.Core`): its public surface includes `Rules` (`clsRulesManager`), edit-session management (`BeginEdit`/`CancelEdit`/`ApplyEdit`), link-management methods, and `IDataErrorInfo` support (`Error`/`Item`), and it owns a `clsRulesManager` instance tied to the V1 rules engine, with broken rules tracked and surfaced through `IDataErrorInfo`.† No direct evidence in this library's source shows these inherited `clsBusinessBase` members (`Rules`, `BeginEdit`, the inherited save path) being invoked — managers instead rely on `LegalManagerBase`'s own parallel lifecycle contract*.

## Design constraints
- No `IBusinessCriteria` implementations exist in this library; all business-tier CRUD for legal-case entities must go through `SAIF.Business.Claim.Legal` — application-layer SQL here is limited to code-table lookups, one scalar lookup, and one stored-procedure insert.
- Two SQL statements (`SQL-019`, `SQL-020`) and one status-code list (`SQL-024`) build query text via runtime string concatenation rather than Oracle bind variables; while the concatenated values are typed (`Decimal`, internally-derived status codes) and not raw user input, this deviates from the bind-variable pattern used elsewhere in the library*.
- Guidewire and Appworx integrations are treated as best-effort, non-transactional side effects: failures are logged (`Logging.clsLogError.CreateError`) but do not roll back or block the primary BOF save.
- Authorization is concentrated in `LegalManagerBase.OnRetrieve()` (claim-level view/conflict/exposure gate, inherited by all 22 managers) and `clsCaseNotesManager` (note-level gate); the remaining concrete managers add no further security-key checks beyond this inherited gate, so action-level authorization beyond screen view is not independently enforced at this layer for most screens*.
- This library's own configuration footprint is minimal: one Environment API key (`cc.ccclaimdataapiurl`) and two call sites of `GetApplicationEnvironment()` for non-Production email-safety branching (DEF email redirection); all Oracle connectivity is inherited from the shared BOF `DataLayer`/`Connection` infrastructure rather than configured locally.

## Architecture diagram
The following diagram shows the high-level component layering and external integration boundaries for this library.

```mermaid
flowchart TD
	UI["Legal.vbproj<br>(web front end)"] --> LMB["LegalManagerBase<br>(shared case-context, auth, consol-case logic)"]
	LMB --> MGRS["22 concrete *Manager classes<br>(Acknowledge, Appeal, Assignment, AttorneyTable, AttyMessages, BoardLog, CaseCost, CaseNotes, CaseSearch, CreateFile, HearingLocation, LegalPerson, MailDate, Maintenance, Outcome, OtherParties, QuickCal, Request, Schedule, Summary, UpdateCase)<br>(one per screen/workflow area)"]
	MGRS --> BIZ["SAIF.Business.Claim.Legal<br>(business objects, IBusinessCriteria CRUD)"]
	BIZ --> DPI["BOF data portal (IDataPortalInfo)"]
	DPI --> ORA[("Oracle<br>pk80001_LEGALNET / pk80001_legalNet")]
	MGRS --> APPSQL["Application-layer SQL<br>(code-table lookups, insertLetterRequest)"]
	APPSQL --> ORA
	MGRS --> APPWORX["SAIF.Services.Appworx<br>(batch print jobs)"]
	MGRS --> GW["Guidewire claim-system REST APIs<br>(GwMatterApi, GWActivityData, GWClaimDataApi)"]
	MGRS --> CACHE["HttpContext.Current.Cache<br>(code-table caching, 8h)"]
```

## Sequence diagram
The following diagram shows the primary case-context load and letter-request flow.

```mermaid
sequenceDiagram
	participant Web as Legal.vbproj (UI)
	participant Mgr as *Manager (LegalManagerBase-derived)
	participant Biz as SAIF.Business.Claim.Legal
	participant DPI as BOF data portal
	participant Ora as Oracle (pk80001_LEGALNET)
	Web->>Mgr: SetCurrentCase(caseID) / CreateCase()
	Mgr->>Biz: clsLegalCase.GetLegalCase(DPI, caseID)
	Biz->>DPI: retrieve request
	DPI->>Ora: stored-procedure / SQL
	Ora-->>DPI: result set
	DPI-->>Biz: business object
	Biz-->>Mgr: clsLegalCase
	Mgr->>Mgr: OnRetrieve() authorization gate
	Mgr-->>Web: case data (or authorization error)
	Web->>Mgr: PrintDEF() / SendReconRequest()
	Mgr->>Ora: insertLetterRequest (pk80001_LEGALNET)
	Ora-->>Mgr: requestNum
	Mgr-->>Web: letter request queued
```

## Related documentation
- [Index](index.md)
- [Overview](overview.md)
- [Dependencies](dependencies.md)
- [Operations and processes](operations-processes.md)
- [Business rules](business-rules.md)
- [Security and authorization](security-authorization.md)
- [Database tables](database-tables.md)
- [SQL catalog](sql/index.md)
- [Configuration](configuration.md)
- [API reference](api/index.md)

> **Note:** Statements marked with `†` are derived from dependency library
> documentation via the Legends CLI. Statements marked with `*` were inferred
> from code structure or contextual evidence. Statements marked with `**` could
> not be confirmed; treat as unknown until verified.

## Sources
- `SAIF.Application.Claim.Legal\SAIF.Application.Claim.Legal.vbproj`
- `SAIF.Application.Claim.Legal\LegalManagerBase.vb`
- `SAIF.Application.Claim.Legal\clsLegalData.vb`
- `SAIF.Application.Claim.Legal\clsAttorneyTableManager.vb`
- `SAIF.Application.Claim.Legal\LegalNet\clsAssignmentManager.vb`
- `SAIF.Application.Claim.Legal\LegalNet\clsRequestManager.vb`
- `SAIF.Application.Claim.Legal\LegalNet\clsScheduleManager.vb`
- `SAIF.Application.Claim.Legal\LegalNet\clsCaseNotesManager.vb`
- `SAIF.Application.Claim.Legal\Web.config`
- `SAIF.Application.Claim.Legal\app.config`